24장. GPU와 로컬 AI 성능 이해하기

1. 로컬 AI에서 왜 GPU 이야기가 나오는가

앞 장에서는 로컬 AI 모델을 선택하는 기준을 살펴보았다.

로컬 AI에서는 모델의 계열, 크기, 한국어 성능, 코드 특화 여부, 라이선스, 양자화 수준을 함께 봐야 한다.
하지만 모델을 골랐다고 해서 바로 끝나는 것은 아니다.

다음 질문이 남는다.

그 모델을 내 컴퓨터나 서버에서 실제로 돌릴 수 있는가?
그리고 업무에 쓸 수 있을 만큼 빠른가?

로컬 AI에서는 하드웨어가 매우 중요하다.

클라우드 AI를 사용할 때는 모델 실행 환경을 클라우드 제공자가 관리한다.
개발자는 API를 호출하고 결과를 받으면 된다.

하지만 로컬 AI는 다르다.

모델 파일
→ 내 PC 또는 사내 서버에 로드
→ CPU나 GPU로 계산
→ 답변 생성

즉, AI 모델을 직접 실행하기 때문에 내 장비의 성능이 응답 속도와 사용 가능 여부를 결정한다.

특히 LLM은 계산량이 많다.
문장을 생성할 때마다 모델 내부에서 많은 행렬 연산이 일어난다.
이런 연산은 CPU보다 GPU가 훨씬 유리한 경우가 많다.

그래서 로컬 AI를 이야기하면 자연스럽게 GPU, VRAM, 양자화, 모델 크기 같은 개념이 함께 등장한다.

이 장에서는 로컬 AI 성능을 이해하는 데 필요한 기본 개념을 살펴본다.

- CPU 실행과 GPU 실행의 차이
- VRAM이 중요한 이유
- 양자화 모델이 필요한 이유
- 7B, 14B, 32B 모델의 의미
- 개발 PC, 맥북, 서버 GPU 선택 기준
- 로컬 AI 성능을 볼 때 주의할 점

이 장의 목표는 GPU 전문가가 되는 것이 아니다.
로컬 AI를 실행할 때 “왜 이 모델은 느린지”, “왜 메모리가 부족한지”, “어떤 장비가 필요한지”를 판단할 수 있게 되는 것이다.

2. CPU 실행과 GPU 실행의 차이

컴퓨터에는 CPU와 GPU가 있다.

CPU는 일반적인 프로그램 실행을 담당한다.
운영체제, 웹 서버, DB, 백엔드 애플리케이션, 브라우저 등 대부분의 작업은 CPU가 중심이다.

GPU는 원래 그래픽 처리를 위해 발전했지만, 대량의 병렬 계산에 강하다.
AI 모델 실행은 많은 행렬 연산을 필요로 하기 때문에 GPU와 잘 맞는다.

단순하게 비교하면 다음과 같다.

CPU로도 로컬 LLM을 실행할 수 있다.

예를 들어 작은 모델이나 양자화 모델은 CPU만으로도 답변을 생성할 수 있다.
하지만 답변 속도가 느릴 수 있다.

CPU 실행:
질문 하나에 답변이 천천히 생성됨
간단한 테스트는 가능
실시간 서비스에는 부족할 수 있음

GPU를 사용하면 답변 속도가 크게 개선될 수 있다.

GPU 실행:
모델 계산을 GPU가 처리
토큰 생성 속도 개선
동시 요청 처리 가능성이 높아짐

물론 GPU가 있다고 항상 빠른 것은 아니다.

다음 조건도 함께 봐야 한다.

- GPU VRAM이 충분한가
- 모델이 GPU에 올라가는가
- 실행 도구가 GPU를 제대로 사용하는가
- 드라이버와 런타임 설정이 맞는가
- 모델 크기와 양자화 수준이 적절한가

로컬 AI에서 CPU는 “실행 가능성”을 제공하고, GPU는 “실사용 가능한 속도”를 제공한다고 이해하면 쉽다.

물론 작은 모델이나 개인 실습에서는 CPU만으로도 충분할 수 있다.
하지만 팀 단위나 서비스 형태로 로컬 AI를 쓰려면 GPU를 고려해야 한다.

3. 로컬 AI에서 VRAM이 중요한 이유

GPU를 이야기할 때 가장 많이 나오는 용어가 VRAM이다.

VRAM은 GPU가 사용하는 전용 메모리다.

로컬 AI에서는 이 VRAM이 매우 중요하다.

AI 모델을 GPU에서 실행하려면 모델의 많은 부분을 VRAM에 올려야 한다.
모델이 VRAM에 올라가지 않으면 GPU를 제대로 활용하기 어렵거나, 실행 자체가 실패할 수 있다.

예를 들어 큰 모델을 실행하려고 할 때 다음과 같은 문제가 생길 수 있다.

out of memory
CUDA out of memory
model load failed
not enough VRAM

이런 오류는 보통 모델이 현재 GPU 메모리에 비해 너무 크다는 뜻이다.

CPU의 RAM과 GPU의 VRAM을 구분해야 한다.

예를 들어 시스템 RAM이 64GB라도 GPU VRAM이 8GB라면 큰 모델을 GPU에 올리는 데 한계가 있다.

RAM 64GB
VRAM 8GB

결과:
시스템 메모리는 충분해 보여도,
GPU에서 큰 모델을 빠르게 실행하기 어려울 수 있음

반대로 VRAM이 넉넉하면 더 큰 모델이나 더 높은 품질의 양자화 모델을 실행할 가능성이 커진다.

VRAM이 크면:
- 더 큰 모델 실행 가능
- 더 높은 정밀도 모델 사용 가능
- 긴 컨텍스트 처리에 유리
- 동시 요청 처리 여지가 커짐

다만 VRAM이 많다고 무조건 모든 문제가 해결되지는 않는다.

CPU, RAM, 디스크 속도, 실행 엔진, 모델 구조, 동시 요청 수, 네트워크 구조도 영향을 준다.

하지만 로컬 LLM에서 가장 먼저 확인할 하드웨어 항목은 보통 VRAM이다.

VRAM은 GPU 전용 메모리다.
로컬 AI에서는 모델을 GPU에 올려 빠르게 실행하기 위해 VRAM 용량이 매우 중요하다.

4. 모델 크기와 메모리 사용량

앞 장에서 모델 이름에 붙는 7B, 14B, 32B 같은 표현을 살펴보았다.

이 숫자는 대략 모델의 파라미터 수를 의미한다.

7B:
약 70억 개 파라미터

14B:
약 140억 개 파라미터

32B:
약 320억 개 파라미터

모델이 클수록 일반적으로 더 많은 메모리와 연산 자원이 필요하다.

단순하게 보면 다음과 같다.

모델 크기 증가
→ 필요한 메모리 증가
→ 계산량 증가
→ 응답 속도 느려질 가능성 증가
→ 더 좋은 하드웨어 필요

물론 모델 크기만으로 품질이 결정되는 것은 아니다.

작지만 잘 튜닝된 모델이 특정 작업에서는 큰 모델보다 나을 수 있다.
하지만 로컬 실행 관점에서는 모델 크기가 매우 현실적인 제약이다.

예를 들어 7B급 모델은 개인 PC에서도 비교적 시도해볼 수 있다.

7B~8B급:
개인 PC 실습에 적합
간단한 요약, 분류, 챗봇 테스트 가능

14B급 모델은 품질이 좋아질 수 있지만 하드웨어 요구사항도 올라간다.

14B급:
품질과 성능의 중간 지점
개발 PC에 따라 실행 가능
응답 속도와 메모리 확인 필요

32B 이상 모델은 본격적인 서버급 환경을 고려해야 할 수 있다.

32B 이상:
답변 품질이 좋아질 수 있음
하지만 VRAM과 RAM 요구량 큼
운영 서버나 고성능 GPU 필요 가능성 높음

모델 크기를 선택할 때는 다음 질문을 해야 한다.

- 이 모델이 내 장비에서 실행되는가?
- 응답 속도가 업무에 쓸 만한가?
- 작은 모델과 비교했을 때 품질 차이가 충분한가?
- 큰 모델을 운영할 만큼 비용과 관리 부담을 감당할 수 있는가?

처음부터 큰 모델을 고르는 것보다 작은 모델부터 테스트하는 것이 좋다.

1단계:
7B~8B급 모델로 흐름 확인

2단계:
14B급 모델로 품질 비교

3단계:
32B 이상 모델은 서버 환경에서 검토

로컬 AI는 “큰 모델이 좋다”가 아니라 “내 하드웨어에서 충분히 빠르고, 우리 업무에 쓸 만한 모델이 좋다”가 기준이다.

5. 양자화 모델이란 무엇인가

로컬 AI에서 큰 모델을 현실적으로 실행하기 위해 자주 사용하는 방법이 양자화다.

양자화는 모델 내부 숫자의 정밀도를 낮춰 메모리 사용량을 줄이는 방식이다.

쉽게 말하면, 모델을 더 가볍게 만드는 기술이다.

원본 모델은 많은 메모리를 필요로 한다.

원본 모델:
품질 좋음
메모리 사용량 큼
실행 부담 큼

양자화 모델은 더 적은 메모리로 실행할 수 있다.

양자화 모델:
메모리 사용량 감소
개인 PC에서도 실행 가능성 증가
응답 속도 개선 가능
품질은 일부 손실 가능

모델 파일 이름에서 Q4, Q5, Q8 같은 표현을 볼 수 있다.

대략적인 의미는 다음과 같다.

초보자는 처음에 Q4나 Q5 모델로 시작하는 경우가 많다.

이유는 간단하다.

- 다운로드 크기가 작다.
- 메모리 요구량이 낮다.
- 개인 PC에서 실행 가능성이 높다.
- 테스트하기 쉽다.

하지만 중요한 업무에서는 양자화 수준에 따른 품질 차이를 확인해야 한다.

예를 들어 고객 문의 요약에서는 Q4 모델도 충분할 수 있다.

작업:
고객 문의 3문장 요약

Q4 모델:
충분히 쓸 만할 수 있음

하지만 복잡한 장애 분석이나 코드 리뷰에서는 더 높은 품질이 필요할 수 있다.

작업:
장애 로그를 보고 원인 후보와 확인 항목 제시

Q4 모델:
핵심을 놓치거나 추정이 많을 수 있음

Q8 또는 더 큰 모델:
품질이 나을 수 있음

양자화는 로컬 AI를 가능하게 해주는 중요한 기술이다.
하지만 품질 손실 가능성이 있으므로 반드시 실제 업무 샘플로 비교해야 한다.

6. 토큰 생성 속도 이해하기

로컬 AI 성능을 이야기할 때 “초당 토큰 수”라는 표현이 자주 나온다.

AI 모델은 답변을 한 번에 완성해서 내보내는 것이 아니라, 토큰을 하나씩 생성한다.

입력:
로그인 API 보안 주의사항 알려줘.

출력 생성:
로그인
API
를
설계할
때는
...

초당 토큰 수는 모델이 1초에 몇 개의 토큰을 생성하는지 나타낸다.

초당 5 tokens:
답변이 느리게 나옴

초당 30 tokens:
상대적으로 자연스럽게 답변이 생성됨

초당 100 tokens 이상:
매우 빠르게 느껴질 수 있음

물론 체감 속도는 답변 길이에 따라 달라진다.

짧은 분류 작업이라면 초당 토큰 수가 낮아도 괜찮을 수 있다.

입력:
문의 유형 분류

출력:
payment

결과:
짧은 출력이므로 속도 부담이 작음

하지만 긴 보고서 초안을 생성한다면 초당 토큰 수가 중요해진다.

출력 2,000 tokens
초당 10 tokens:
약 200초

초당 50 tokens:
약 40초

로컬 AI 성능을 테스트할 때는 단순히 “답변이 나왔다”가 아니라 실제 업무에 필요한 응답 시간을 봐야 한다.

고객 문의 요약:
5초 이내면 충분할 수 있음

실시간 채팅 보조:
1초 이내가 필요할 수 있음

문서 분석:
비동기 처리라면 1분 이상도 가능할 수 있음

개발자 코드 설명:
10~20초 정도도 허용될 수 있음

기능마다 적정 속도 기준이 다르다.

따라서 로컬 AI 성능은 반드시 업무 시나리오 기준으로 측정해야 한다.

7. 첫 토큰 시간과 전체 응답 시간

AI 응답 속도에는 두 가지 관점이 있다.

첫 토큰 시간
전체 응답 시간

첫 토큰 시간은 사용자가 요청한 뒤 AI가 첫 번째 토큰을 생성하기까지 걸리는 시간이다.

전체 응답 시간은 답변이 완전히 끝날 때까지 걸리는 시간이다.

예를 들어 다음과 같다.

요청 시작
→ 2초 후 첫 문장 표시
→ 12초 후 전체 답변 완료

이 경우 첫 토큰 시간은 2초이고, 전체 응답 시간은 12초다.

챗봇 UI에서는 첫 토큰 시간이 중요하다.

사용자는 답변이 조금이라도 나오기 시작하면 시스템이 동작한다고 느낀다.

첫 토큰이 빠름:
사용자가 기다릴 수 있음

첫 토큰이 늦음:
멈춘 것처럼 느낄 수 있음

반면 서버 내부에서 JSON 결과를 받아 후속 처리하는 기능은 전체 응답 시간이 더 중요하다.

AI 분류 결과
→ 서버가 JSON 파싱
→ DB 저장
→ 후속 작업 실행

이 경우 중간에 토큰이 조금씩 나와도 의미가 적다.
완성된 응답이 빨리 필요하다.

로컬 AI에서는 모델 로딩 시간도 영향을 줄 수 있다.

모델이 이미 메모리에 올라와 있으면 빠르게 응답할 수 있다.
하지만 요청 시점에 모델을 새로 로드하면 첫 응답이 매우 느려질 수 있다.

모델이 이미 로드됨:
빠르게 응답 시작

요청 때마다 모델 로드:
첫 요청이 매우 느림

운영 환경에서는 모델을 미리 로드해두거나, 서버가 시작될 때 모델을 준비하는 방식이 필요할 수 있다.

8. 동시 요청 처리 성능

개발 PC에서 혼자 로컬 AI를 사용할 때는 동시 요청을 크게 신경 쓰지 않아도 된다.

하지만 팀이나 서비스에서 사용하려면 동시 요청 처리가 중요하다.

예를 들어 사용자 1명이 요청할 때는 응답이 5초 걸린다고 해보자.

사용자 1명:
응답 5초

그런데 사용자 10명이 동시에 요청하면 어떻게 될까?

사용자 10명 동시 요청:
GPU 자원 경쟁
대기열 발생
응답 시간 증가
일부 요청 timeout 가능

로컬 AI 서버는 일반 API 서버처럼 많은 요청을 동시에 처리하기 어렵다.

특히 큰 모델은 GPU 메모리를 많이 사용하고, 한 번에 처리할 수 있는 요청 수가 제한될 수 있다.

동시 요청을 처리하는 방식은 여러 가지가 있다.

- 요청 큐를 둔다.
- 동시 실행 수를 제한한다.
- 작은 모델과 큰 모델을 분리한다.
- GPU 서버를 여러 대 둔다.
- 배치 처리 가능한 작업은 묶어서 처리한다.
- 긴 작업은 비동기로 처리한다.

예를 들어 사내 문서 검색 AI를 팀 단위로 제공한다고 해보자.

동시 사용자:
20명

평균 질문 응답 시간:
8초

문제:
점심시간 이후나 장애 상황에 질문이 몰릴 수 있음

이 경우 다음을 설계해야 한다.

- 한 사용자당 동시 요청 1개 제한
- 전체 동시 처리 수 제한
- 대기열 안내
- 오래 걸리는 질문 timeout
- 필요 시 클라우드 AI fallback

로컬 AI는 GPU 자원이 한정되어 있다.
따라서 동시 요청을 무제한 받으면 서비스 전체가 느려질 수 있다.

9. 개발 PC, 맥북, 서버 GPU의 차이

로컬 AI를 실행할 수 있는 환경은 다양하다.

- 일반 윈도우 노트북
- 게이밍 PC
- 맥북
- 워크스테이션
- 사내 GPU 서버
- 클라우드 GPU 인스턴스

각 환경은 장단점이 다르다.

일반 노트북

일반 노트북에서도 작은 모델은 실행할 수 있다.

하지만 CPU 실행이거나 내장 GPU 중심이면 속도가 느릴 수 있다.

장점:
바로 테스트 가능

단점:
큰 모델 실행 어려움
응답 속도 느릴 수 있음
발열과 배터리 문제

게이밍 PC 또는 워크스테이션

NVIDIA GPU가 있는 PC는 로컬 AI 실험에 유리하다.

장점:
GPU 가속 가능
VRAM이 충분하면 다양한 모델 테스트 가능
비교적 빠른 응답

단점:
전력, 발열, 소음
운영 서버로 쓰기에는 관리 필요

맥북

Apple Silicon 기반 맥북은 로컬 AI 실험에 많이 사용된다.

통합 메모리 구조 덕분에 일정 규모의 모델을 실행하기 좋다.

장점:
개발 환경으로 편함
전력 효율 좋음
로컬 AI 실험에 적합

단점:
서버 GPU와는 구조가 다름
대규모 동시 처리에는 한계
일부 도구는 NVIDIA/CUDA 환경과 다르게 동작

맥북의 통합 메모리는 CPU와 GPU가 메모리를 공유하는 구조다.
그래서 일반적인 VRAM 개념과 조금 다르게 봐야 한다.

사내 GPU 서버

팀이나 조직에서 로컬 AI를 운영하려면 GPU 서버를 고려할 수 있다.

장점:
팀 단위 서비스 가능
더 큰 모델 실행 가능
운영 환경 구성 가능
모니터링과 접근 제어 가능

단점:
초기 비용 큼
운영 관리 필요
GPU 자원 스케줄링 필요
장애 대응 필요

클라우드 GPU 인스턴스

직접 물리 서버를 구매하지 않고 클라우드 GPU 인스턴스에 오픈소스 모델을 올릴 수도 있다.

장점:
필요할 때 빠르게 생성 가능
서버 구매 부담 없음
실험에 유용

단점:
시간당 비용 발생
데이터 전송과 보안 고려 필요
관리형 AI보다 운영 부담 큼

중요한 것은 목적에 맞는 환경을 고르는 것이다.

10. 개발 PC로 로컬 AI를 돌릴 때 주의할 점

개발 PC에서 로컬 AI를 실행하는 것은 좋은 학습 방법이다.

하지만 몇 가지 주의할 점이 있다.

첫 번째는 발열이다.

LLM 추론은 CPU나 GPU를 많이 사용한다. 노트북에서 오래 실행하면 발열이 커지고 팬 소음이 증가할 수 있다.

긴 답변 생성
→ CPU/GPU 사용률 증가
→ 발열 증가
→ 성능 저하 가능

두 번째는 배터리 소모다.

노트북에서 로컬 AI를 돌리면 배터리가 빠르게 줄어들 수 있다.

세 번째는 다른 개발 작업에 영향을 줄 수 있다.

로컬 모델 실행 중:
IDE 느려짐
Docker 느려짐
브라우저 느려짐
빌드 속도 저하

네 번째는 저장공간이다.

모델 파일은 크다.
여러 모델을 다운로드하면 디스크 공간이 빠르게 줄어든다.

모델 A 5GB
모델 B 8GB
모델 C 20GB
→ 총 33GB 이상

다섯 번째는 보안이다.

개발 PC에 내부 문서나 코드, 로그를 넣고 로컬 AI로 처리한다면 PC 자체의 보안도 중요하다.

- 디스크 암호화
- 화면 잠금
- 모델과 문서 저장 위치 관리
- 외부 공유 폴더 주의
- 로그 파일 관리

개발 PC에서 로컬 AI를 쓸 때는 학습과 실험 목적에 적합하다.
팀 공용 서비스로 쓰려면 별도 서버 환경을 준비하는 것이 좋다.

11. 서버에서 로컬 AI를 운영할 때 고려할 점

서버에서 로컬 AI를 운영하려면 일반 백엔드 서비스보다 더 많은 자원 관리가 필요하다.

먼저 GPU 자원을 관리해야 한다.

- 어떤 모델이 GPU에 올라가 있는가
- VRAM 사용량은 얼마나 되는가
- 동시 요청이 얼마나 되는가
- GPU 사용률은 얼마나 되는가
- 큐 대기 시간이 늘어나고 있는가

두 번째는 모델 프로세스 관리다.

모델 서버가 죽으면 자동으로 재시작되어야 한다.

모델 서버 장애
→ Health Check 실패
→ 프로세스 재시작
→ 알림 발송

세 번째는 배포 전략이다.

모델을 바꾸면 답변 품질이 달라질 수 있다.
따라서 모델 버전 변경도 배포처럼 관리해야 한다.

모델 v1
→ 평가
→ 모델 v2 배포
→ 품질 비교
→ 문제 시 rollback

네 번째는 접근 제어다.

내부 AI 서버라고 해서 누구나 호출할 수 있으면 안 된다.

- 내부망 접근 제한
- 서비스 계정 기반 호출
- API 인증
- 사용자별 사용량 제한
- 관리자 기능 분리

다섯 번째는 로그와 모니터링이다.

로컬 AI 서버에서도 다음 지표를 봐야 한다.

- 요청 수
- 응답 시간
- 실패율
- 첫 토큰 시간
- 초당 토큰 수
- GPU 사용률
- VRAM 사용량
- 큐 대기 시간
- 모델별 사용량

서버에서 로컬 AI를 운영하는 것은 작은 AI 플랫폼을 운영하는 것과 비슷하다.
단순히 모델을 실행하는 것보다 운영 체계를 만드는 것이 중요하다.

12. 로컬 AI 성능 측정 방법

로컬 AI를 테스트할 때는 체감만으로 판단하면 안 된다.

다음 지표를 측정하면 좋다.

예를 들어 모델 테스트 결과를 다음처럼 기록할 수 있다.

모델:
example-llm-8b-q5

환경:
Windows PC, RAM 64GB, GPU VRAM 12GB

작업:
고객 문의 3문장 요약

결과:
첫 토큰 시간 1.2초
전체 응답 시간 4.8초
평균 출력 120 tokens
품질 양호

다른 모델과 비교할 수도 있다.

모델 A:
응답 빠름, 요약 품질 보통

모델 B:
응답 느림, 요약 품질 좋음

모델 C:
한국어 어색함, JSON 형식 자주 실패

성능 측정은 모델 선택과 운영 판단에 필요하다.

- 이 모델을 계속 쓸 것인가?
- 더 작은 모델로 바꿔도 되는가?
- 더 큰 모델을 쓸 가치가 있는가?
- GPU 서버가 필요한가?
- 클라우드 AI와 나눠야 하는가?

로컬 AI는 반드시 실제 업무 샘플로 측정해야 한다.

13. 성능과 품질의 균형

로컬 AI에서 성능과 품질은 균형 문제다.

빠른 모델이 항상 좋은 것은 아니다.
품질 좋은 모델이 항상 실무에 적합한 것도 아니다.

예를 들어 작은 모델은 빠르다.

장점:
응답 빠름
메모리 적게 사용
동시 처리 유리

단점:
복잡한 질문에 약함
환각 가능성
도메인 이해 부족

큰 모델은 품질이 좋을 수 있다.

장점:
복잡한 질문 처리 가능성 높음
긴 문맥 이해에 유리
답변 품질 개선 가능

단점:
느림
메모리 많이 사용
운영 비용 증가

따라서 기능별로 기준을 달리해야 한다.

예를 들어 실시간 채팅 분류는 빠른 응답이 중요하다.

채팅 메시지 입력
→ 즉시 분류
→ 유해 메시지 여부 판단

이 작업에 너무 큰 모델을 사용하면 지연이 커질 수 있다.

반대로 장애 로그 분석은 속도보다 품질이 중요할 수 있다.

장애 로그 분석
→ 원인 후보
→ 확인 항목
→ 임시 대응 방안

여기서 너무 작은 모델을 쓰면 잘못된 원인 추정을 할 수 있다.

로컬 AI 성능 설계의 핵심은 기능별로 속도와 품질 기준을 분리하는 것이다.

14. 로컬 AI 성능 최적화 방향

로컬 AI가 느릴 때는 여러 방향으로 개선할 수 있다.

첫 번째는 더 작은 모델을 사용하는 것이다.

32B 모델이 너무 느림
→ 14B 모델 테스트

14B 모델도 느림
→ 7B 모델 테스트

두 번째는 양자화 수준을 조정하는 것이다.

Q8 모델이 너무 무거움
→ Q5 또는 Q4 모델 테스트

세 번째는 입력을 줄이는 것이다.

로컬 AI도 입력이 길면 느려진다.

긴 로그 전체
→ 에러 로그만 추출

문서 전체
→ 관련 섹션만 전달

대화 전체
→ 최근 대화와 요약만 전달

네 번째는 출력 길이를 제한하는 것이다.

자세히 설명해줘
→ 5줄 이내로 요약해줘

전체 분석 보고서 작성
→ 원인 후보, 확인 항목, 대응 방안만 표로 작성

다섯 번째는 작업을 비동기로 처리하는 것이다.

긴 문서 분석
→ 즉시 응답 대신 작업 등록
→ 완료 후 결과 확인

여섯 번째는 모델을 용도별로 나누는 것이다.

짧은 분류:
작은 모델

복잡한 분석:
큰 모델

민감 정보:
로컬 모델

일반 지식:
클라우드 모델

성능 최적화는 단순히 하드웨어를 더 좋은 것으로 바꾸는 것만이 아니다.

입력, 출력, 모델, 작업 방식, 아키텍처를 함께 조정해야 한다.

15. 하드웨어를 선택할 때의 현실적인 기준

로컬 AI용 하드웨어를 고를 때는 먼저 목적을 정해야 한다.

개인 실습용인가?
팀 내부 도구용인가?
운영 서비스용인가?
민감 정보 처리용인가?
대량 처리용인가?

목적에 따라 기준이 달라진다.

개인 실습용

개인 실습용이라면 너무 높은 사양이 필요하지 않을 수 있다.

목표:
로컬 AI 개념 이해
작은 모델 실행
간단한 요약과 질의응답 테스트

기준:
적당한 RAM
충분한 저장공간
가능하면 GPU 또는 Apple Silicon

개발자 업무 보조용

개발자가 코드 설명, 문서 요약, 간단한 로컬 RAG를 쓰려면 조금 더 여유 있는 장비가 좋다.

목표:
코드 설명
개발 문서 검색
테스트 데이터 생성
간단한 리뷰 보조

기준:
충분한 RAM
빠른 SSD
가능하면 GPU 또는 통합 메모리 여유

팀 내부 서버용

팀 단위로 쓰려면 동시 요청과 안정성을 봐야 한다.

목표:
여러 사용자가 내부 AI 도구 사용
문서 검색 챗봇
운영 로그 요약

기준:
GPU VRAM
RAM
모니터링
네트워크
장애 대응
접근 권한 관리

운영 서비스용

외부 사용자나 대규모 내부 사용자를 대상으로 한다면 더 신중해야 한다.

목표:
안정적인 응답
동시 요청 처리
장애 대응
확장성

기준:
GPU 서버 구성
로드밸런싱
큐
모니터링
fallback
운영 인력

하드웨어 선택은 단순히 “비싼 GPU를 사면 된다”가 아니다.

실제 처리할 작업, 사용자 수, 품질 기준, 보안 요구사항에 따라 결정해야 한다.

16. 로컬 AI 성능 테스트 체크리스트

로컬 AI 성능을 확인할 때는 다음 체크리스트를 사용할 수 있다.

테스트는 반드시 실제 업무 시나리오로 해야 한다.

나쁜 테스트:
"안녕?"만 입력하고 빠르다고 판단

좋은 테스트:
고객 문의 100건 요약
장애 로그 20건 분석
문서 기반 질문 50건
코드 diff 20건 리뷰

실제 업무 데이터로 테스트해야 성능과 품질을 제대로 판단할 수 있다.

17. 정리

로컬 AI에서 GPU와 하드웨어는 매우 중요하다.

클라우드 AI에서는 모델 실행 환경을 제공자가 관리하지만, 로컬 AI에서는 우리가 직접 모델을 실행해야 한다.
따라서 CPU, GPU, RAM, VRAM, 저장공간이 모델 실행 가능 여부와 응답 속도에 직접 영향을 준다.

CPU만으로도 작은 모델을 실행할 수 있지만, 실사용 가능한 속도를 원한다면 GPU가 유리하다.
특히 GPU의 VRAM은 모델을 올리고 빠르게 추론하는 데 중요한 자원이다.

모델 크기도 현실적인 제약이다.
7B, 14B, 32B 같은 모델 크기는 품질뿐 아니라 메모리 요구사항과 응답 속도에 영향을 준다.
양자화 모델은 더 적은 메모리로 모델을 실행할 수 있게 해주지만, 품질 손실 가능성도 있다.

로컬 AI 성능은 단순히 “빠르다” 또는 “느리다”로 판단하면 안 된다.

- 첫 토큰 시간
- 전체 응답 시간
- 초당 토큰 수
- RAM 사용량
- VRAM 사용량
- 동시 요청 처리
- 응답 품질

이런 지표를 함께 봐야 한다.

개발 PC에서 테스트하는 것과 서버에서 운영하는 것은 다르다.
개인 실습은 작은 모델로 충분할 수 있지만, 팀 내부 도구나 운영 서비스는 동시 요청, 모니터링, 장애 대응까지 고려해야 한다.

이 장에서 기억해야 할 핵심은 하나다.

로컬 AI 성능은 모델만으로 결정되지 않는다.
모델 크기, 양자화, 입력 길이, 출력 길이, GPU, VRAM, 동시 요청, 운영 구조가 함께 성능을 만든다.

24장 핵심 요약